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(54) System and method for facilitating trusted transactions between businesses 



(57) In an e-commerce system, on-line assurances 
of party identity or other parameters can be obtained 
from financial institutions acting as assurors. A signed 
message is sent from a sending party via an intermedi- 
ate service provider. The intermediate party obtains the 
identity of the receiver and receiver's assuror from the 



receiving party and the obtaining assurances from both 
the sending and receiving party assurors. The assured 
message is then sent to the receiving party who replies 
with a receipt which is sent from the intermediate party 
to the sending party as an assured receipt. The inter- 
mediate party plays no part in the underlying business 
transaction. 
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Description 

FIELD OF THE INVENTION 

[0001] This invention relates to a system and method 
for facilitating transactions between businesses. In par- 
ticular, it is concerned with the provision of on-line guar- 
antees or assurances by companies engaged in busi- 
ness-to-business (B2B) e-commerce, although it is also 
applicable to consumer-to-business e-commerce 
(C2B). 

BACKGROUND TO THE INVENTION 

[0002] When two companies transact over a network 
such as the Internet, some messages that are ex- 
changed require guarantees or assurances. A guaran- 
tee or assurance is an obligation on behalf of one party 
to fulfil a commitment or an instruction: messages which 
represent such a commitment or instruction must be 
guaranteed. As a simple example, a receiver needs an 
assurance about a sender's identity and the time and 
date a message was sent. 

[0003] In business-to-business (B2B) transactions, 
companies could rely on their financial institutions to 
provide such assurances. Financial institutions already 
provide loans and financial assurances to customers. 
Figure 1 illustrates a scenario where a receiver 10 ob- 
tains an assurance by sending a 'certificate valid?' mes- 
sage 12 to the financial institution 14 who issued the 
sender's certificate, the financial institution then sends 
the assurance message 16 back to the receiver. This is 
disadvantageous as it requires extra work by the receiv- 
er who also may not have a relationship with the finan- 
cial institution. It is also disadvantageous as the natural 
message flow is between the receiver and sender which 
is interrupted to allow the financial institution to validate 
a certificate. 

SUMMARY OF THE INVENTION 

[0004] The present invention aims to overcome the 
abovementioned disadvantages with the prior art meth- 
od and apparatus. 

[0005] In accordance with the invention, this aim is 
met by a system in which an assurance is integrated 
with the message sent to the receiver. This arrangement 
greatly reduces the amount of messaging required. 
[0006] The invention is defined by the independent 
claims to which reference should be made. 
[0007] In one embodiment of the invention, an inter- 
mediate party is arranged between the sending party 
and the receiving party. The intermediate party receives 
messages, which may be signed, from the sending par- 
ty, and obtains an assurance from a sending party as- 
suror. The intermediate party then sends the message, 
as an assured message, to the receiving party. 
[0008] In one embodiment, the intermediate party al- 



so obtains an assurance from the receiving party assu- 
ror. When an assured message is received at the receiv- 
ing party, a receipt is sent to the intermediate party which 
sends it as an assured receipt to the sending party. 

5 [0009] Preferably, on receipt of a message, the inter- 
mediate party logs it, adds a timestamp and reference 
and verifies any signature. It then determines the send- 
er's identity and its assuror's identity. 
[0010] Preferably, assuring messages, that is those 

10 from the assurance provider, are logged before they are 
sent to the receiving party. The receipts are also logged 
before being sent by the intermediate party as assured 
receipts. 

[001 1 ] Embodiments of the invention have the advan- 
15 tage that message flow is greatly simplified. The assur- 
ances are integrated with the messaging, not requested 
as a separate action. They have the further advantage 
that customers can obtain on-line assurances for e- 
commerce transactions from financial institutions. 
20 [0012] A preferred embodiment has the further ad- 
vantage that the intermediate party, through its logging, 
timestamping and referencing of messages, can pro- 
vide an on-line notarisation enabling resolution of dis- 
putes between parties. 

25 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0013] Embodiments of the invention will now be de- 
scribed, by way of example only, and with reference to 
30 the accompanying drawings in which: 

Figure 1 is an overview of a known model for pro- 
viding assurances; 

Figure 2 is an overview of the model for providing 
35 assurances adopted by the present invention; 

Figure 3 illustrates the contractual relationship be- 
tween parties to an exchange of messaging; 
Figure 4 illustrates the levels of contractual relation- 
ships in the system; 
40 Figure 5 illustrates the message flow in a system 
embodying the present invention; 
Figure 6 is a schematic view of the topology of a 
system embodying the invention. 



[001 4] Referring to the figures, the purpose of the sys- 
tem is to facilitate trusted business-to-business (B2B) 
e-commerce by enabling businesses to obtain on-line 
assurances from their financial institution(s). Banks or 
other financial institutions can use the system to be de- 
scribed to provide on-line assurances and e-trust serv- 
ices to corporate customers who subscribe to the sys- 
tem. Although the following description is limited to a 
B2B application, the invention may also be applied to a 
consumer-to-business (C2B) system. 
[0015] The system to be described operates over a 
communications network, preferably a combination of 
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the Internet and a private network. In essence it is a 
messaging service which adds assurances to e-com- 
merce messages, enabling trusted e-commerce. 
[0016] The system to be described operates on the 
principle that assurances are attached before they are 
received by a receiver. Preferably, assurances are add- 
ed both to the sender and receiver. The receiver's as- 
suror may also be involved. This is illustrated In Figure 
2, very schematically, in which the financial institution is 
shown at 14 and the receiver at 10. 
[0017] Figure 3 shows the contractual relationship be- 
tween the various parties to a transaction. The sender 
20 and receiver 30 each have a contractual relationship 
with their own assurors, 22 and 32. Assurances can be 
exchanged by the assurors through a third party 34 es- 
tablishing an indirect relationship between the sender 
and the receiver. Such an arrangement may be used to 
provide more than the provision of identity assurances 
and may extend to the provision of on-line notarisation, 
a legal framework that makes messages binding, and 
guarantees such as the ability to pay. The system oper- 
ates by providing an assurance service to which finan- 
cial institutions sign up as assurors and businesses sign 
up as customers. 

[0018] Messages exchanged between senders and 

receivers may be made legally binding by establishing 
contractual relationships between senders, receivers 
and their banks, and by establishing contractual rela- 
tionships between the financial institutions and the serv- 
ice provider 34. Message exchange also takes place un- 
der the terms of Contract Law. 

[0019] The contractual relationship between sub- 
scribers and assurors will set out details of service lev- 
els, prices, procedures and other factors determining 
the provision of assurance services as the assuror to 
the subscriber. It may refer to a Certification Practices 
Statement. 

[0020] The contractual relationship between the as- 
surors and the service providers defines service levels 
between the service provider and the assurors as well 
as defining the service levels the guarantor can promise 
to provide the subscribers. 

[0021 ] This two tier contractual relationship Is Illustrat- 
ed in figure 4 with the subscriber shown at 50, the serv- 
ice provider at 60 and the assurors at 70. 
[0022] Each of the levels of contract may refer to a 
rulebook established by the service provider to which 
the parties are then bound. Thus, the assurors have an 
explicit relationship with the service provider 34 and an 
Implied relationship with other assurors who have a con- 
tractual relationship with the service provider. 
[0023] Referring to figure 5, the message flow In a 
transaction will now be described. 
[0024] The purpose of the following sequence is for 
the sender to send a signed message to a receiver 
which is received by the receiver as an assured mes- 
sage who returns a receipt which is received by the 
sender as an assured receipt. 



[0025] The first stage is for the sender to send a 
signed message to the service provider. In figure 5 this 
Is shown by pathway 1. The signed message requires 
a financial Institution's assurance and is created by any 
5 suitable application at the sender, for example a browser 
or an ERP system which signs the message and sends 
It to the service provider. 

[0026] At the second stage, the service provider re- 
ceives the signed message from the sender, logs it and 
adds to it a timestamp and individual reference number. 
It then verifies the signature using its public key. The use 
and verification of signed electronic messages Is well 
understood and will not be described further. 
[0027] The service provider then interprets the re- 
ceived signed message to determine the sender's Iden- 
tity, its certificate and the identity of the sender's assuror. 
It then establishes a connection to the receiver to obtain 
its certificate and its assuror's identity (not shown). The 
service provider will then send an assurance request to 
the sender's assuror relative to the sender and to the 
receiver's assuror relative to the receiver. 
[0028] These two assurance request messages are 
shown at 2 in figure 5. Thus, in this stage, the service 
provider 34 has requested assured identity from the as- 
surors 22,32. 

[0029] At the next stage, shown as 3 in figure 5, the 
assurors confirm, respectively, the identity of the sender 
and receiver to the service provider. The assurors each 
receive and process the assurance request made by the 
service provider and send an assurance response back 
to the service provider. 

[0030] The service provider then forwards the as- 
sured message to the receiver as shown at 4 In figure 
5. This can take place once the two assurors have con- 
firmed the assurance. The service provider constructs 
an assured message using the original signed message 
and the timestamp and reference number that were ap- 
plied when the message was received at the service 
provider. The guaranteed message is first logged and 
then sent to the receiver. 

[0031] The receiver, at 5, receives the assured mes- 
sage from the service provider, authenticates the serv- 
ice provider's signature which is attached to the mes- 
sage and can then rely on that message. 
[0032] The receiver then acknowledges receipt of the 
message by returning a signed receipt to the service 
provider, illustrated at 6 in figure 5. The service provider 
then constructs an assured receipt by adding the as- 
sured identity obtained from the receiver's assuror to the 
signed receipt, logs the assured receipt and fonwards it 
to the initial sender. This step is shown at 7 in figure 5. 
[0033] From the description given above, it will be ap- 
preciated that messages passing through the service 
provider 34 are timestamped and logged. Timestamping 
ensures that a message was sent at a universal, com- 
monly accepted time. Logging allows messages to be 
retrieved at a later date so that disputes can be resolved. 
Thus, the system and method described can be used to 
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provide an on-line notarisation service. 
[0034] As mentioned above, the contractual agree- 
ment between the various parties may refer to a rule- 
book. The following description sets out a summary of 
the major obligations on the subscribers, assurors and 5 
service provide that may be required. 

Subscribers 

[0035] Subscribers are required to manage their keys io 
and security in a responsible manner, for example by 
maintaining exclusive access to the private key. Send- 
ers must send signed messages to the service providers 
requesting assurances when asked by the receiver and 
be bound by assured messages forwarded by the serv- ^5 
ice provider to the same extent, and with the same effect 
of law as if it had existed in a manually signed form. Like- 
wise, receivers must notify the sender when a message 
must be routed through the service provider, must re- 
ceive assured messages from the service provider, rely 20 
on the sender's identity, public key and signature and 
promptly return a signed receipt to the sender. 

Assurors 

25 

[0036] Assurors are required to maintain subscriber 
records, verify that a sender's private key corresponds 
to its public key and, preferably, ensure that subscriber 
identities and public keys are unique. They must revoke 
a public key when requested by a subscriber. Assurors 30 
support subscribers by providing first line support and 
arbitration in the event of a dispute. 
[0037] Assurors also confirm or refuse to confirm as- 
surances by receiving an assurance request from the 
service provider and providing the response in an as- 35 
surance response to the service provider. 
[0038] Assurors connect to and communicate with the 
service provider's server and manage the liability risk of 
its services. 

40 

Service Provider 

[0039] The service provider is required to construct 
and forward assured messages to the receiver by re- 
ceiving messages from the sender; send assurance re- ^5 
quests to the parties' assurors; obtain assurance re- 
sponses from the assurors; and construct assured mes- 
sages from the signed message if both assurors confirm 
the assurances. Furthermore the service provider is re- 
quired to receive signed receipts from the receiver and 50 
construct and forward an assured receipt to the sender. 
The service provider is obliged to protect the security of 
its server and ensure that it can operate at all times and 
produce evidence to assurors in the event of disputes. 
[0040] It will be appreciated that the obligations set 55 
out above are merely one example of how the system 
can work what the subscribers are required to do with 
their keys is set out in the contract with the assuror. The 



role of the service provider may be limited to provide a 
norm for this contract. 

[0041] The example described above, and the asso- 
ciated rules, relate specifically to the provision of as- 
sured identity by financial institutions. It will be appreci- 
ated that the system can be adapted to provide other 
assurances without departing from the scope of the in- 
vention. Examples include the ability to assure payment, 
account signing authority and creditworthiness. The 
message flow and rulebooks for each of these may be 
different. 

[0042] Figure 6 illustrates, schematically, the topology 
of a preferred implementation of the invention. The serv- 
ice supplier is a server which incorporates a message 
routing function using Internet protocols. The communi- 
cations between the assurors and the service provider 
are preferably across a dedicated communications 
pathway such as SWIFTNet InterAct. The system sup- 
ports Identrus compliant X.509v3 certificates and appli- 
cations. Other certificates and applications may be sup- 
ported. The communications between the service pro- 
vider and the subscribers are via the Internet using 
standard Internet communications protocols. The mes- 
sages are preferably sent in XML format with the XML 
envelope embedding the actual message and X.509v3 
certificate. 

[0043] Assurors are required to register and their sta- 
tus must be verified frequently. One way of doing this is 
to use the Identrus system mentioned in which Indentrus 
acts as the registrar for assurors. 
[0044] It will be appreciated from the foregoing that 
the method and system embodying the invention enable 
a subscriber to obtain assurances from its financial in- 
stitution, such as confirmation that a certificate issued 
by the financial institution and used to sign an e-com- 
merce message is still valid. The counterparty receiving 
the message has the assurance that the identity of the 
sender has been verified. The receiver has the addition- 
al assurance that the messages have been logged and 
timestamped by the service provider, which can be re- 
lied on in the event of a dispute. The sender has the 
same benefit as the receiver returns a receipt which is 
assured by the and logged by the service provider. Busi- 
nesses may exchange messages over the Internet, or 
any other communications network via the service pro- 
vider to enable banks to apply trust, or assurances, to 
the receiver when the message is on its way to the re- 
ceiver. 

[0045] From the point of view of the financial institu- 
tion, the method and system embodying the invention 
provide a platform that financial institution can use to 
provide on-line assurances and e-trust services to cor- 
porate customers enabling them to play an active role 
in B2B e-commerce. The financial institution can main- 
tain a direct relationship with their customers as market, 
sell and support the system using their own e-trust brand 
to their customers. Those customers sign an agreement 
with their financial institution rather than with the service 
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provider. Financial institutions, wlien requested to, can 
add assurances to e-commerce messages sent be- 
tween two businesses, adding value without interrupting 
the natural message flow. 

[0046] Various modifications and developments be- 
yond those already mentioned are possible and will oc- 
cur to those skilled in the art without departing from the 
spirit and scope of the invention. 

Claims 

1 . A method of sending an electronic message from 
a sending party to a receiving party, the message 
being received by the second party with an assur- 
ance, the method comprising the steps of: 

sending an assurance request from said send- 
ing party to an assuror; 

attaching an assurance received from the as- 
suror to said message; and forwarding said as- 
sured message to said receiving party. 

2. A method according to claim 1 , wherein said step 
of sending said assurance request from said send- 
ing party to an assuror comprises the steps of: 

sending said message from said sending party 
to an intermediate party; and 
sending the assurance request from said inter- 
mediate party to a sender's assuror. 

3. A method according to claim 1 , wherein prior to 
said step of sending a message requesting an as- 
surance, said intermediate party performs the steps 
of: 

logging said message from said sending party; 
adding atimestamp to said message; 
adding a reference to said message; and 
verifying said message. 

4. A method according to claim 3, wherein said mes- 
sage is a message signed with a signature, and the 
step of verifying said message further comprises 
verifying the signature. 

5. A method according to claim 3, wherein said in- 
termediate party performs the further steps of: 

determining the assuror's identity; 
determining the sending party's identity; and 
determining the identity of the receiving party's 
assuror. 

6. A method according to claim 5, wherein the step 

of determining the identities of the receiving party 
and the receiving party's assuror comprises con- 



tacting the receiving party. 

7. A method according to claim 5, wherein the step 
of sending said assurance request from the sending 
5 party to a assuror further comprises: 

sending an assured request message from 
the intermediate party to the receiving party's assu- 
ror. 

10 8. A method according to claim 2, wherein the step 
of sending said message further comprises receiv- 
ing an assurance from the sender's assuror, and 
said step of attaching the assurance to the message 
is performed by the intermediate party. 

15 

9. A method according to claim 5, wherein the step 
of sending said message further comprises receiv- 
ing an assurance from the receiver's assuror. 

20 1 0. A method according to claim 8, wherein the step 
of attaching the assurance to the message includes 
attaching a timestamp and reference to the mes- 
sage, said timestamp and reference having been 
assigned by the intermediate party on receipt of the 

25 message from the sender by the intermediate party. 

1 1 . A method according to claim 1 0, comprising re- 
ceiving the assured message at the receiving party 
from the intermediate party; and verifying a signa- 
ge ture applied to the message by the intermediate 

party. 

12. A method of sending an assured message from 
a sending party to a receiving party, the method 

35 comprising the steps of: 

sending an electronic message from the send- 
ing party to an intermediate party; 
obtaining an assurance at the intermediate par- 

40 ty; 

on receipt of the assurance, constructing an as- 
sured message from the electronic message 
and the assurance; sending the assured mes- 
sage from the intermediate party to the receiv- 

45 ing party. 

13. A method according to claim 1 or 12, further 
comprising sending a receipt from the receiving par- 
ty to the intermediate party after receipt of the as- 

50 sured message. 

14. A method according to claim 13, wherein the 
receipt is a signed receipt. 

55 1 5. A method according to claim 1 2, comprising for- 
warding the assured message to the sending party 
with the assurance received from the receiving par- 
ty's assuror. 
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16. A method according to claim 12, wlierein tine 
message sent 

from the sending party includes a signature, com- 
prising: logging the message on receipt at the inter- 
mediate party; adding a timestamp and a reference 5 
to the message and verifying the signature. 

17. A method according to claim 16, wherein the 
step of constructing the assured message uses the 
received signed message, the timestamp and the io 
reference. 

18. A method according to claim 13, wherein, when 
the receipt is received by the intermediate party, the 
intermediate party sends an assured receipt to the 15 
sending party. 

19. A method according to claim 12, further com- 
prising the step of: 

obtaining an assurance from the receiving 20 
party assuror by the intermediate party; and where- 
in the construction and sending of the assured mes- 
sage occurs only when assurances are received 
from the sending party assuror and the receiving 
party assuror. 25 

20. A method according to claim 1 9, wherein on re- 
ceipt of the assured message at the receiving party, 
the receiving party sends a receipt to the interme- 
diate party, and the intermediate party adds the as- so 
surance received from the receiving party's assuror 

to the receipt to form an assured receipt and sends 
the assured receipt to the sending party. 

21. A method according to claim 19, wherein the 35 
step of obtaining an assurance from a receiving par- 
ty assuror by the intermediate party comprises re- 
questing from the receiving party the identity of the 
receiving party's assuror and sending an assurance 
request to the receiving party assuror on receipt of 40 
the receiving party's identity. 

24. A method according to claim 23, wherein the 
message is encrypted using public/private key en- 
cryption, further comprising requesting the receiv- ^5 
ing party's certificate when the assuror identity re- 
quest is sent. 

22. A method of providing on-line notarisation for 
electronic messages sent from a sending party to a 50 
receiving party, comprising the steps of: 

sending a message from the sending party to 
an intermediate party; 

logging receipt of the message at the interme- 55 
diate party; 

applying a timestamp to the message; 
assigning a reference to the message; 



obtaining an assurance from a sending party 
assuror at the intermediate party; 
and, on receipt of the assurance, sending an 
assured message from the intermediate party 
to the receiving party. 

23. Apparatus for sending an electronic message 
from a sending party to a receiving party, the mes- 
sage being received by the receiving party with an 
assurance, comprising: 

a message sending device for sending the 

message from said sending party to an assuror; 
means for attaching an assurance to said mes- 
sage; and 

means for forwarding said assured message to 
said receiving party. 

24. Apparatus according to claim 23, further includ- 
ing: 

an intermediate party; and 
means at the intermediate party for sending a 
message from the intermediate party to a send- 
er's assuror requesting a guarantee. 

25. Apparatus according to claim 24, wherein the 
intermediate party comprises: 

a logger for logging said message from said 
sending party; 

a timestamper for adding a timestamp to said 
message; 

a reference adder for adding a reference to said 
message; and 

a verifier for verifying the message. 

26. Apparatus according to claim 25, wherein said 

message is signed with a signature, and the verifier 
for said message further comprises means for ver- 
ifying the signature. 

27. Apparatus according to claim 25, wherein said 

intermediate party further comprises a sending par- 
ty identifier for determining the sending party's iden- 
tity; 

an assuror identifier for determining the assu- 
ror's identity; and 

a receiving party assuror identifier for determin- 
ing the identity of the receiving party's assuror. 

28. Apparatus according to claim 27, wherein the 
receiving party assuror identifier comprises means 
for contacting the receiving party. 

29. Apparatus according to claim 27, wherein the 
message sending device further comprises: 
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means for sending an assurance request 
message from the intermediate party to the receiv- 
ing party's assuror. 

30. Apparatus according to claim 24, wherein the 5 
message sending device further comprises means 

for receiving an assurance from the sender's assu- 
ror; and said intermediate device includes said 
means for attaching the assurance to the message 
is performed by the intermediate party. io 

31. Apparatus according to claim 27, wherein the 

electronic message sending device further com- 
prises means for receiving a guarantee from the re- 
ceiver's assuror. 15 

32. Apparatus according to claim 30, wherein the 
means for attaching the assurance to the message 
includes: 

means for attaching a timestamp and refer- 20 
ence to the messages, said timestamp and refer- 
ence having been assigned by the intermediate par- 
ty on receipt of the message from the sender by the 
intermediate party. 

25 

33. Apparatus according to claim 32, comprising a 
receiving party for receiving the assured message 
from the intermediate party, the receiving party hav- 
ing a verifier for verifying a signature applied to the 
message by the intermediate party. so 

34. Apparatus according to claim 23, further com- 
prising a receipt sender of the receiving party for 
sending a receipt from the receiving party to the in- 
termediate party after receipt of the assured mes- 35 
sage. 

35. Apparatus according to claim 34, wherein the 
intermediate party comprises means for fonwarding 

the assured receipt to the sending party with the as- 40 
surance received from the receiving party's assuror. 

36. Apparatus for sending an assured message 
from a sending party to a receiving party, compris- 
ing: 45 

a sending party; an intermediate party; an as- 
suror; and a receiving party: 
wherein the sending party comprises a mes- 
sage sender for sending the message to the in- 50 
termed late party; 

the intermediate party comprises means for ob- 
taining an assurance from the sending party as- 
suror; and an assured message forming and 
sending device for, on receipt of the assurance, 55 
constructing an assured message and sending 
the assured message to the receiving party. 



37. Apparatus according to claim 36, wherein the 
message sent from the sending party includes asig- 
nature, comprising, at the intermediate party, a 
message logger for logging the message on receipt, 
a timestamper for adding a timestamp, a referencer 
for adding a reference to the message, and a verifier 
for verifying the signature. 

38. Apparatus according to claim 37, wherein the 
guaranteed message constructing device attaches 
the timestamp generated by the timestamper and 
the reference generated by the reference to the 
signed message. 

39. Apparatus according to claim 36, wherein the 
intermediate party includes an assured receipt 
sender for sending an assured receipt to the send- 
ing party when a receipt is received from the receiv- 
ing party. 

40. Apparatus according to claim 36, wherein the 
intermediate party further comprises means for ob- 
taining an assurance from a receiving party assuror 
at the intermediate party; and wherein the means 
for constructing and sending the assured message 
constructs and sends the message occurs only 
when assurances are received from the sending 
party assuror and the receiving party assuror. 

41. Apparatus according to claim 40, wherein the 
receiving party comprises a receipt sender which, 
on receipt of the assured message at the receiving 
party, the receiving party sends a receipt to the in- 
termediate party and the intermediate party com- 
prises an assured receipt sender which adds the as- 
surance received from the receiving party's assuror 
to the receipt to form an assured receipt and sends 
the assured receipt to the sending party. 

42. Apparatus according to claim 33, wherein the 
intermediate party further includes means for re- 
questing the identity of the receiving party's assuror 
and sending an assurance request to the receiving 
party assuror on receipt of that identity. 

43. Apparatus for sending an assured electronic 

message from a sending party to a receiving party, 
comprising: an intermediate party, wherein the 
sending party comprises a message sender for 
sending a signed message to an intermediate party; 
the intermediate party comprising: 

an assuror identifier for establishing the identity 
of a receiving party assuror; 
an assurance requester for sending an assur- 
ance request to a sending party assuror and the 
receiving party assuror; 
an assured message sender which on receipt 
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of an assurance from each of the sending party 
assuror and receiving party assuror, sends an 
assured message from the intermediate party 
to the receiving party; and 
an assured receipt sender for sending an as- 
sured receipt from the intermediate party to the 
sending party after the assured message has 
been received by the receiving party. 

44. Apparatus according to claim 43, wherein the 
intermediate party further comprises; 

a logger for logging the signed message; 

a timestamper for attaching a timestamp to the 

signed message; 

a referencer for attaching a reference to the 

signed message; and 

a verifier for verifying the signature. 

45. Apparatus according to claim 44, wherein the 
assuror identifier comprises means for sending an 
assuror identity request from the intermediate party 
to the receiving party. 

46. Apparatus according to claim 45, wherein the 

message is encrypted using public/private key en- 
cryption, further comprising a certificate requestor 
for requesting the receiving party's certificate when 
the assuror identity request is sent. 

47. Apparatus for providing on-line notarisation for 
electronic messages sent from a sending party to a 
receiving party, comprising: at an intermediate par- 
ty; 

a message sender for sending a message from 
the sending party to the intermediate party; 
a logger for logging receipt of the message at 
the intermediate party; 

a timestamper for applying a timestamp to the 
message; 

a referencer for assigning a reference to the 
message; 

an assurance obtainer for obtaining an assur- 
ance from a sending party assuror at the inter- 
mediate party; and 

an assured message sender for sending, on re- 
ceipt of the assurance, an assured message 
from the intermediate party to the receiving par- 
ty. 
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a logger for logging the receipt at the interme- 
diate party; and 

an assured receipt sender for sending an as- 
sured receipt to the sending party. 

49. An intermediate agent for use in a system for 
sending an electronic message from a sending par- 
ty to a receiving party, the message being received 
by the sending party with an assurance, the system 
including the sending party, the receiving party, and 
a sending party assuror; wherein the intermediate 
agent is arranged to communicate with the sending 
party, the receiving party and the sending party as- 
suror and comprises: 

means for obtaining an assurance relating to 
the sending party from the sending party assu- 
ror; and 

means for sending the received message as an 
assured message to the receiving party. 

50. An intermediate agent according to claim 49, 
wherein the system further comprises: a receiving 
party assuror; and the intermediate agent further 
comprises means for obtaining an assurance relat- 
ing to the receiving party from the receiving party 
assuror. 

51. An intermediate agent according to claim 50, 
further comprising means for receiving a receipt 
from the receiving party when the receiving party 
has received an assured message; and means for 
sending the receipt as an assured receipt to the 
sending party. 
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48. Apparatus according to claim 47, further com- 
prising: 



a receipt sender for sending a receipt from the 
receiving party to the intermediate party on re- 
ceipt of the assured message at the receiving 
party; 
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